The performance of large scale production environments is an area of considerable interest as businesses become more diverse and applications become more complex. Data systems must remain reliable and available. Reliability and performance can be a considerable issue in the face of rapid system or application scaling such as would be experienced in a merger of two large corporations or in the implementation of a new server intensive application such as a web media application involving streaming video.
A goal of modern capacity planners is to optimize business applications on very large and complex systems with perhaps thousands of server nodes that are often geographically dispersed. The workloads processed by these applications and the infrastructure in which they execute change over time. New and different users and user behaviors change the level and mix of the workloads. The servers, networks and their configurations change for a variety of business reasons. Capacity planners must determine a) the impact of such anticipated or hypothetical changes, b) when anticipated increases in workload levels will exceed the capacity of the existing infrastructure, and c) what solutions to predicted performance bottlenecks will be most effective. Capacity planners accomplish these goals by measuring the current performance of their business applications, building performance models using those measurements, and using those models to predict how performance will change in response to anticipated or hypothetical changes to the workloads and infrastructure.
Server consolidation is one type of change to the IT infrastructure that occurs with increasing frequency in order to simplify server management, reduce space and power requirements, and other reasons—including simplification and potential improvement of performance management. However, the number of server consolidation options in a modem large IT environment is enormous. IT managers and capacity planners cannot effectively choose among the myriad of server consolidation options by trial and error or rules of thumb. They need the ability to evaluate different server consolidation scenarios rapidly and easily in order to make good choices before implementing those choices. The present disclosure provides that ability.
In some situations, low performance of a production system may be analyzed. To relieve the situation, a workload reassignment or new equipment may be needed. The planning and implementation of the nature of the equipment to be deployed or the workload reassignment requires assembling a test environment and scaling analysis.
In yet other situations, newer faster equipment may be deployed to replace older slower equipment. For example, server and storage technology are generally replaced every four to five years to take advantage of advances in speed, power and efficiency. In this case the IT capacity manager is required to plan a detailed server consolidation where the workload of a number of servers is consolidated onto a smaller number of servers. In the prior art, this type of system consolidation is also carried out with a test environment.
Referring to FIG. 1, a modern large-scale computer network known as a production environment is depicted. In a production environment, a data center 1 serves as a central repository for distributed applications and data access to other networks. The data center includes a business application server cluster 2, a database server cluster 3 and a web application server cluster 4. The business application server cluster, data server cluster and web application server are interconnected and provide responses to requests for information from external sources such as shown at 11 and 12. Requests for information can come from company intranets such as shown at 5 which support other computer networks. In this example, a single company internet can support an operations network 8, a marketing department network 7 and an execution and financial network 6. Requests for information are derived from applications running on the various networks which generate workloads. Data center 1 in this example also services requests and provides responses through the internet 6 to retail customers 10 and other corporate customers 9.
A general data center server migration situation is shown in FIG. 2A in which a source or base data center configuration 20 is to be changed to a destination data center configuration 30. A set of Z workloads 18 defined as {w}=w1, w2, . . . wz are arriving at source data center configuration 20 at base arrival rates AB({w}) 15 during a base time interval. Workloads 18 are requests for specific computer instructions to be processed by the base data center. For example, the workloads may be generated by a number of internet users simultaneously utilizing their web browsers to view and interact with web content from a particular company's web servers such as viewing catalogs of merchandise, investigating online specifications, placing orders or providing online payments. A destination data center configuration 30 is prescribed to accept workloads 18 at a set of arrival rates A({w}) 16 where A({w})16 is scaled from base arrival rates AB({w}) by some scaling factor G({w}), where G(w)=1 represents the processing of the workloads by the destination data center configuration at the base (original) workload arrival rates.
Source data center configuration 20 comprises a set of N server clusters 25-1, 25-2, . . . 25-N. Furthermore, server cluster 25-1 comprises a set of server nodes 28-1 and similarly, server clusters 25-1, . . . 25-N contain sets of server nodes 28-2, . . . 28-N (not shown). Server clusters 25-1, . . . 25-N functionally operates to service workloads 18 at arrival rates AB({w}) 15. The dimension of a server cluster is defined as the number of server nodes in the cluster. Source parameters 22 describe configuration parameters of the source data center configuration 20.
Destination data center configuration 30 comprises a set of M server clusters 35-1, 35-2, . . . 35-M. Server cluster 35-1 comprises a set of server nodes 38-1 and similarly, server clusters 35-2, . . . 35-M contain sets of server nodes 38-2, . . . 38-M (not shown). Server clusters 35-1, . . . 35-M functionally operates to service workloads 18 at arrival rates A({w}) 16. Note that the destination data center configuration 30 may contain a subset of the base server clusters 25-1 . . . 25-M. Furthermore, note that N or M may equal 1 (one) and that the dimension of a given server cluster may equal 1 (one) so that either the source data center configuration 20 or destination data center configuration 30 may contain only one server node. Destination parameters 32 describe the source data center configuration 30.
In FIG. 2B, a server node 50 typical of the server nodes in the source data center configuration 20 or of destination data center configuration 30. Server node 50 comprises a set of central processing units (CPUs) 55 arranged on an appropriate electronics hardware platform (not shown) for executing computational and I/O instructions. The hardware platform accommodates on-board dynamic random-access memory 70 accessible by CPUs 55 for dynamic data storage. Attached to CPUs 55 and contained in server node 50 are a set of disk drives 60 for persistent storage of data and typically comprised of magnetic read-write hard drives. Also attached to CPUs 55 and contained within server node 50 are a set of network interface cards NICs 65 which provide a means by which the CPUs 55 attach to networks.
The CPU dimension of a server cluster (e.g. server cluster 25-1) is the number of distinct CPUs contained in that server cluster. The disk drive dimension and NIC dimension is similarly defined as the number of respective units in a given server cluster.
In migrating from source data center configuration 20 to destination data center configuration 30, a potentially large number of configuration parameters 22 and 32 must be specified or computed. Source parameters 22 are measured and specified typically as a baseline. It is the object of the present disclosure to greatly simplify the process of manipulating source parameters 22 by utilizing stored configurations in combination with a set of GUI based wizards for easily specifying servers and reassigning workloads to transform source parameters 22 into destination parameters 32. Additionally, workloads 18 may be grown on a number of time intervals so that the performance sensitivity of the destination data center configuration 30 to workload may be plotted as a function of time.
The term data center is used throughout this document generally to mean any collection of server clusters organized to perform work on a given workload. The data center may be geographically dispersed so that the server clusters may exist in different geographical locations up to a global scale configuration. The term workload reassignment is used to describe a specific type of data center migration scenario in FIG. 2A and where a specified fraction of each workload 18 is removed from source data center server clusters 25-1,25-N and distributed to destination server clusters 35-1, . . . 35-M. Server consolidation typically implies a situation where the number of servers or number of server clusters are smaller in the destination data center configuration than in the source configuration, though the present disclosure applies equally well when the number of destination servers or clusters is larger. In server consolidation, as defined in this specification, the workloads from selected source server clusters 25-1, . . . 25-N are fully reassigned and distributed to the destination server clusters 35-1, . . . 35-M. The present disclosure applies more generally to situations whereby the IT manager desires to understand what the performance of a new data center configuration will be relative to his current configuration so as to optimize the new configuration for performance, cost, upgradeability or other feature. The disclosure will allow the IT manager to investigate a number of data center configuration scenarios to perform such an optimization. An embodiment of the disclosure provides the capacity to model server consolidation and workload reassignment as well as other situations.
There are a number of products on the market today to aid the performance engineer in the capacity planning process. Current state of the art in capacity planning tools for server consolidation typically include automatic population of baseline (pre-consolidation) models from databases or performance measurement or monitoring tools. In some cases agents must be present on the monitored devices. Additionally, these products offer rudimentary capabilities to move workloads from one or more baseline servers to a new server.
In terms of ease of use, the state-of-the-art remains cumbersome. For example, when modeling workload and hardware changes in the case of dissimilar hardware between the source and destination servers, scaling factors may need to be calculated external to the planning tool and entered by the user. As another example, the display and organization of scenarios to the user is always done in a flat list.
The present disclosure, a server migration planning tool, addresses the cumbersome nature of current planning tools by providing a comprehensive and intuitive GUI/wizard for creating server consolidation scenarios. The wizard steps users through selecting source servers, identifying and/or creating destination servers, and moving workloads under either a workload reassignment process or server consolidation process. Multiple reassignments may be combined with a single scenario. The present disclosure provides for flexible grouping of source and destination servers into tiers of similar servers in a tree list view for ease of selection.
The present disclosure also provides the performance engineer with improved insight by providing for the definition of destination servers within a consolidation scenario to be any combination of existing or hypothetical servers. Furthermore, a server may be both a source and destination for server consolidation or workload reassignment.
In yet another improvement to the art, different workloads or fractions of workloads may be sent to different destinations in a given scenario; the workload reassignments thus made for the given scenario may precede any scenario (except the base configuration) or it may follow any scenario.
In addition to improvements in the ease of use and flexibility of capacity planning tools for server migration, the transformation engine in the present disclosure for transforming a source data center configuration into a new data center configuration provides for significant improvement. The transformation calculations automatically scale to account for hardware/configuration differences, such as changing to a different model of computer, adding CPU's, or changing device speeds. Furthermore, the calculation of memory utilization after server consolidation is a novel and useful feature of the present disclosure.
In an embodiment of the present disclosure, the description and use of a novel parameterization, speed independent service demand (SISD), greatly facilitates scaling performance metrics between different hardware platforms. Ordinarily (without SISD), computer performance models must specify service demands in time units such as seconds, which depend upon the original device speeds. To evaluate what-if scenarios involving changes to device speeds, the model must scale the service demands by the ratios of the old and new device speeds which require the model to remember the speeds of the original devices. Very complex what-if scenarios such as server consolidation require multiple such scalings to be performed carefully. SISD simplifies the calculations of service times in any computer performance model for what-if scenarios involving changes in device speeds or reassignment of work to new devices with different device speeds. This inventive technique has applicability to performance models of any technology, not just computer-related technology, where service times depend upon the speed of the devices being modeled.